Method and apparatus for sve redundancy

ABSTRACT

Systems and methods for providing service virtualization endpoint (SVE) redundancy in a two-node, active-standby form. An active-standby pair of SVEs register with a cloud-centric-network control point (CCN-CP) as a single service node (SN) using a virtual IP address for both a control-plane and a data-plane. At any given time, only the active SVE is a host for the control-plane and the data-plane. When a failover happens, the hosting operation is taken over by the standby SVE, therefore the failover will be transparent to CCN-CP and the SN.

BACKGROUND

Approximately a third of all IT spending is consumed in the data center.With such a large share of IT Total Cost of Ownership (TCO) concentratedin the data center, changes in architecture can materially impact ITspend and corporate competitiveness. While the trends of virtualizationand cloud computing offer data center architecture opportunities, thereare also challenges. High-end data center design is challenged withincreasing complexity, the need for greater workload mobility andreduced energy consumption. Traffic patterns have also shiftedsignificantly, from primarily client-server or as commonly referred toas north-to-south flows, to a combination of client-server andserver-server or east-to-west plus north-to-south streams. These shiftshave wreaked havoc on application response time and end user experience,since the network is not designed for these Brownian motion type flows.

High availability in the data center refers not only to device-specificavailability and uptime, but also to network design and features thatprevent downtime in the case of a catastrophic event. Uptime in thiscontext refers to availability of the switch to direct traffic. As moreand more equipment is added to the data center network, the highavailability of the network may be undermined. Network architects needto consider design best practices o reduce single points of failure andachieve network uptime goals in the data center.

SUMMARY

Systems and methods for providing service virtualization endpoint (SVE)redundancy in a two-node, active-standby form. An active-standby pair ofSVEs register with a cloud-centric-network control point (CCN-CP) as asingle service node (SN) using a virtual IP address for both acontrol-plane and a data-plane. At any given time, only the active SVEis a host for the control-plane and the data-plane. When a failoverhappens, the hosting operation is taken over by the standby SVE,therefore the failover will be transparent to CCN-CP and the SN.

In accordance with a method of the present disclosure, redundancy in aservice insertion architecture may be include: providing a serviceclassifier (SCL) that performs traffic classification and service headerinsertion; providing a first services virtualization endpoint (SVE) anda second services virtualization endpoint (SVE) at a virtual IP address,the first SVE and the second SVE each providing access to service nodes;replicating service chaining information from the first SVE to thesecond SVE; redirecting packets received at the SCL to the first SVE atthe virtual IP address; directing the packets in accordance with amapping for processing; and returning the packets to the SCL.

In accordance with service insertion architecture of the presentdisclosure, there is provided a cloud-centric-network (CCN) controlpoint that maintains an ordered list of service nodes and a pathconnecting each element in the order; a service classifier (SCL); one ormore services virtualization endpoints (SVEs); and one or more servicenodes (SNs) that provide services within the service insertionarchitecture. The one SVE registers with the CCN at a virtual IPaddress, and wherein a packet enters the service insertion architectureat the SCL and is directed to the SNs via the one SVE at the virtual IPaddress.

Other systems, methods, features and/or advantages will be or may becomeapparent to one with skill in the art upon examination of the followingdrawings and detailed description. It is intended that all suchadditional systems, methods, features and/or advantages be includedwithin this description and be protected by the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The components in the drawings are not necessarily to scale relative toeach other. Like reference numerals designate corresponding partsthroughout the several views.

FIG. 1 illustrates an exemplary Service Insertion Architecture (SIA)infrastructure having a Services Virtualization Endpoint (SVE) withredundancy;

FIG. 2 illustrates an exemplary operational flow diagram for providingSVEs within the SIA Infrastructure of FIG. 1 where the SVEs haveredundancy; and

FIGS. 3-7 illustrate data flows within the SIA Infrastructure during theexecution of the operational flow of FIG. 2.

DETAILED DESCRIPTION

As will be described in detail herein with reference to severalexemplary implementations, systems and methods for providing ServicesVirtualization Endpoint (SVE) redundancy and load-sharing in a ServiceInsertion Architecture (SIA) infrastructure are provided. With referenceto FIG. 1, the SIA 100 may consist of a control plane and data plane.The SIA control plane functionality may include Cloud-Centric-Network(CCN) Control Point, a Service Classifier (SCL), one or more ServicesVirtualization Endpoints (SVE) and a Service Node (SN). The SIA dataplane functionality may include the Service Classifier (SCL), the one ormore Services Virtualization Endpoints (SVE), and the Service Node (SN).

The Cloud Centric Network (CCN) Control Point (CP) is the centralcontrol plane entity in the SIA domain. The CCN CP maintains the mappingbetween the classification context and the service paths. Each servicepath may contain one classification context, an ordered list of servicenodes and a path connecting each element in the order as defined in thepolicy. In addition to maintaining information about active services,the CCN CP aids in the creation and binding of service paths, thusfacilitating the setup of the data path. For high availability, CCN CPsimplemented on multiple chassis may be clustered using an NX-OS ClusterInfrastructure. All the configuration of CCN CPs is maintainedconsistent throughout the cluster using Reliable Group Communicationfacility of NX-OS Cluster Infrastructure.

The Service Classifier (SCL) performs initial traffic classification andservice header insertion. SCL is the entry point in the data path to SIAdomain and is typically present at the edge of a network. The SCL is thefirst (head) node in a service-path. The SCL mainly interacts with theCCN CP in the control-plane and with SVE in the data plane.

The Services Virtualization Endpoint (SVE) front-ends service nodes andoff-loads the complex SIA data plane functions such as service chaining,transport encapsulation, decapsulation and routing from the actualservice. For high availability, SVEs running on two different chassismay be grouped together using Virtual PortChannel (VPC). In thisconfiguration one of the SVEs functions as an active SVE while the otherwill be in standby mode from Control Path perspective. CCN CP willduplicate configuration between the two SVEs. This aspect of thedisclosure is discussed in further detail below.

The Service Node (SN) delivers the actual service in the SIAservice-path. The service node communicates with CCN-CP in the controland SVE in the data plane. In the data plane, the SVE bridges datapackets between the SCL or another SVE and the service node. In otherwords, in the data plane, the SCL intercepts the interested traffic andredirects it into the service path comprising of ordered service nodes.Each Service Node (SN) is front-ended by an SVE. After the trafficreaches SVE, the traffic flows from one service node to another in theorder it was provisioned until it reaches the last service node. When apacket flows to another service node, it is always via the SVE. The lastservice node returns the traffic back to SVE which decides whether toredirect it back to SCL or forward it. The Service Nodes is alwaysLayer-2 adjacent to the SVE. When there is more than one SVEs present,they can be either Layer-2 or Layer-3 away between two SVEs.

The SIA data plane functions may include classification and SIA contexttagging, redirection and service selection. With respect toclassification and SIA context tagging, the classifier intercepts theinterested traffic and inserts a shared context in the packet. Theshared context primarily constitutes a unique id (e.g., a trafficclassification id) and service ordering information for next serviceselection in the service path the tagged traffic is redirected. This idconveys the classification context, i.e., the result of classification,information to the service nodes in the service path. Service nodes mayuse this id to apply service specific polices to the packets. The idremains constant across a service path. In addition, it also representsa service path the traffic is flowing in a SIA domain. It may alsorepresent the service path in an SIA domain. If the path is linear, itis often referred to as a chain. The id is used to derive the path tothe next hop at each service node. The id may be used to virtualizeservices in the network which means that the irrespective of the servicedevice location, the packet tagged with the same classification id willalways undergo the same set of services in the SIA domain.

With respect to redirection, each SIA physical device at data planelevel, may redirect the tagged packets to the next hop physical devicein the service path. The redirection is done using the availabletransport mechanisms of the underlying network. For example, a GREtunnel may be used for this purpose. This redirection tunnel may beshared between two physically or logically adjacent SIA devices and isused to carry entire SIA traffic for multiple service paths that flowsbetween the two devices.

In accordance with some implementations, SVE functionality on SVE1 andSVE2 may be clustered together so that they act as though there is onlyone SVE from the CCN's perspective. During bootstrap configuration, oneSVE may be assigned as master, the other slave. A virtual name, avirtual IP and a virtual MAC may be hosted by the master SVE. Both SVEsadvertise their capabilities and their corresponding master slave roles.The CCN is responsible for keeping both SVEs informed of the servicepath segments creation/deletion. As a result, the Ternary ContentAddressable Memory (TCAM) entries of both master and slave SVEs may beidentical and ready to forward packets along the service path. Thisensures that the data path traffic can actually enter any of the SVEnodes and can get forwarded directly to the service or back to the SCLwithout having to traverse the peer link (vPC) that connects both SVEnodes together.

The SCL is configured to communicate to a virtual IP address exposed viaFirst Hop Redundancy Protocol (FHRP) to the master SVE entity. Forexample, where there is one Service, one SCL and two SVEs, both SVEsmaintain identical TCAM entries. If SCL is Layer-2 adjacent to SVE, thenvPC can be formed between SCL and the two SVEs. The traffic from SCL toSVE reaches either SVE, depending on flow-based load-balancing at SCL.That SVE forwards the packet to the service. There is no need for thepackets to flow between SVE-1 and SVE-2. If SCL is Layer-3 adjacent toSVE, it is possible that the packet can follow a route through SVE2before it gets to SVE1. Again, SVE-2 can directly forward the packet ifthere is a TCAM match.

Similarly, for the reverse traffic from the service going back to SVE.Either SVE can handle the traffic and send it back to SCL. The slave SVEkeeps a regular health check against the master SVE. If the master SVEfails, the slave SVE will take over the virtual IP, virtual MAC andvirtual name and become the master.

In some implementations, the scheme can further be enhanced such thatonly certain TCAM entries are synchronized between the two SVEs. For theTCAM entries which are not synchronized, a user can specify the loadbalancing weights among the two SVEs. For example, the user may want oneSVE to handle more traffic, For the TCAM entries which are synchronized,a user can rely on RBH (result based hash) in the ASIC forload-balancing.

In some implementations, one of the SVEs may be configured with moreTCAM entries than the other SVE. As such the former SVE will carry moretraffic than the later SVE. The above may be implemented for loadbalancing between the SVEs. This may also be based that SVE-1 is morepowerful than SVE-2 (not the other way around), and SVE function cost ismore than packet forwarding function (e.g., the SVE is implemented insoftware instead of in a hardware ASIC).

With reference to FIG. 1, SVE redundancy may be provided such that ifone SVE fails (e.g. SVE-1), a user does not lose services provided by afailed SVE, but rather is serviced by a surviving SVE (e.g., SVE-2).

With reference to FIG. 2, there is illustrated an exemplary operationalflow diagram for providing an SVE in the SIA 100 of FIG. 1 where theSVEs provide redundancy. FIGS. 3-7 illustrate data flows within the SIA100 during the execution of the operational flow of FIG. 2. As notedabove, SVE redundancy may be provided such that if one SVE fails (e.g.SVE-1), a user does not lose services provided by a failed SVE, butrather is serviced by a surviving SVE (e.g., SVE-2).

At 202, the SVE-1 and SVE-2 register with the CCN using a Hot StandbyRouter Protocol (HSRP) Virtual IP address. The Hot Standby RouterProtocol (HSRP) is a CISCO protocol that provides network redundancy forIP networks, ensuring that user traffic immediately and transparentlyrecovers from first hop failures in network edge devices or accesscircuits. A virtual IP address (VIP) is an IP address that is notconnected to a specific computer or network interface card (NIC) on acomputer. Incoming packets are sent to the VIP address, but they areredirected to physical network interfaces. VIPs may be used forconnection redundancy. For example, a VIP address may still be availableif a computer or NIC fails because an alternative computer or NICreplies to connections. As shown in FIG. 3, during the operation 202,one SVE (e.g., SVE-1) registers with the CCN. As such SVE-1 and SVE-2have a common Virtual IP, and the CCN will only see one SVE, i.e.,SVE-1.

At 204, the CCN duplicates the service chaining configuration to SVE-1and SVE-2 to keep them identically configured. As a result, the TCAMentries in SVE-1 and SVE-2 are identically programmed. Additionally oralternatively, the TCAM entries in SVE-1 and SVE-2 may be synchronizedby communicating the entries between each other.

At 206, services begin communicating to the Virtual IP that representsSVE. As shown in FIG. 4, SVE-1 and SVE-2 will have the HSRP virtual IPswitch virtual interface (SVI) at the access side of SIA 100. As such,Service-1 and Service-2 communicate to the Virtual IP, and packets aredirected to the active SVE, e.g., SVE-1.

At 208, the SCL encapsulates the packet with an SIA header and redirectspackets to SVE-1 for a service path that goes from Service-1 toService-2 based on the Virtual IP. As shown in FIG. 5, an inbound packetreceived by the SCL is classified and send to SVE-1. At 210, SVE-1redirects packet to Service-1, as the packet is destined for thatservice. As shown in FIG. 5, SVE-1 forwards the packet to Service-1.

At 212, packets received from Service-1 are returned. As shown in FIG.6, packets may be sent from Service-1 to SVE-2 based on a port channelhash. In some implementations, SVE-2 may be programmed with theidentical TCAM entries as SVE-1. As such, SVE-2 does not need to forwardthe return packet to SVE-1 over peer link, rather SVE-2 can service thepacket directly. With reference to FIG. 7, SVE-2 may forward the packetto Service 2 for further processing.

At 214, packets are received back from Service-2 are sent to SVE-1 orSVE-2. At 216, SVE-1 or SVE-2 sends the packet to SCL, or remove the SIAheader and route the payload normally, As shown in FIG. 7, the packetsare returned to SVE-2 and then sent to the SCL or otherwise routed.

Thus, in accordance with the operation flow of FIG. 2, from thestandpoint of the CCN, there is only one SVE (SVE-1) that is identifiedby the Virtual IP, whereas SVE-2 is a standby. However, from a data pathstandpoint, both SVE-1 and SVE-2 are active and able to serve packets.

In some implementations, the SVE-1 may be implemented in software. Assuch, a larger TCAM table size may be possible. In such animplementation, all TCAM entries may be synchronized, as table size isnot a limitation.

It should be understood that the various techniques described herein maybe implemented in connection with hardware or software or, whereappropriate, with a combination of both. Thus, the methods and apparatusof the presently disclosed subject matter, or certain aspects orportions thereof, may take the form of program code (i.e., instructions)embodied in tangible media, such as floppy diskettes, CD-ROMs, harddrives, or any other machine-readable storage medium wherein, when theprogram code is loaded into and executed by a machine, such as acomputer, the machine becomes an apparatus for practicing the presentlydisclosed subject matter. In the case of program code execution onprogrammable computers, the computing device generally includes aprocessor, a storage medium readable by the processor (includingvolatile and non-volatile memory and/or storage elements), at least oneinput device, and at least one output device. One or more programs mayimplement or utilize the processes described in connection with thepresently disclosed subject matter, e.g., through the use of anapplication programming interface (API), reusable controls, or the like.Such programs may be implemented in a high level procedural orobject-oriented programming language to communicate with a computersystem. However, the program(s) can be implemented in assembly ormachine language, if desired. In any case, the language may be acompiled or interpreted language and it may be combined with hardwareimplementations.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed:
 1. A method for providing redundancy in a serviceinsertion architecture, comprising: providing a service classifier (SCL)that performs traffic classification and service header insertion;providing a first services virtualization endpoint (SVE) and a secondservices virtualization endpoint (SVE) at a virtual IP address, thefirst SVE and the second SVE each providing access to service nodes;replicating service chaining information from the first SVE to thesecond SVE; redirecting packets received at the SCL to the first SVE atthe virtual IP address; directing the packets in accordance with amapping for processing; and returning the packets to the SCL.
 2. Themethod of claim 1, further comprising registering both the first SVE andthe second SVE at the virtual IP address.
 3. The method of claim 2,further comprising: providing a cloud centric network control point(CCN-CP) that maintains the mapping, which is an ordered list of theservice nodes and a path connecting the service nodes; and registeringthe first SVE and the second SVE with the CCN-CP at the virtual IPaddress such that the CCN-CP only sees the first SVE.
 4. The method ofclaim 3, further comprising: storing the service chaining information ina ternary content addressable memory (TCAM); and replicating, by theCCN-CP, the TCAM entries between the first SVE and the second SVE. 5.The method of claim 1, wherein the service nodes communicate the virtualIP address.
 6. The method of claim 5, further comprising directed thepackets to the first SVE.
 7. The method of claim 1, further comprising:storing the service chaining information in a ternary contentaddressable memory (TCAM); and replicating the TCAM entries between thefirst SVE and the second SVE, wherein the first SVE and the second SVEcommunicate directly with each other.
 8. The method of claim 1, furthercomprising: detecting a failure of the first SVE; redirecting packetsreceived at the SCL to the second SVE at the virtual IP address; anddirecting the packets in accordance with the mapping for processing. 9.The method of claim 1, storing the service chaining information in aternary content addressable memory (TCAM); and replicating predeterminedones of the TCAM entries between the first SVE and the second SVE. 10.The method of claim 9, wherein a RBH (result based hash) is used forload-balancing.
 11. The method of claim 1, further comprising: storingthe service chaining information in a ternary content addressable memory(TCAM); and replicating the TCAM entries between the first SVE and thesecond SVE.
 12. The method of claim 1, further comprising: storing theservice chaining information in a ternary content addressable memory(TCAM); and configuring the first SVE with more TCAM entries than thesecond SVE.
 13. A service insertion architecture, comprising: acloud-centric-network (CCN) control point that maintains an ordered listof service nodes and a path connecting each element in the order; aservice classifier (SCL); one or more services virtualization endpoints(SVEs); and one or more service nodes (SNs) that provide services withinthe service insertion architecture, wherein one SVE registers with theCCN at a virtual IP address, and wherein a packet enters the serviceinsertion architecture at the SCL and is directed to the SNs via the oneSVE at the virtual IP address.
 14. The service insertion architecture ofclaim 13, wherein if the one SVE fails, a second SVE services thepacket.
 15. The service insertion architecture of claim 13, whereinTernary Content Addressable Memory (TCAM) entries of the SVEs aremaintained to be identical.
 16. The service insertion architecture ofclaim 15, wherein the TCAM entries are replicated between the SVEs bythe CCN.
 17. The service insertion architecture of claim 15, wherein theTCAM entries are replicated by the SVEs communicating directly with eachother.
 18. The service insertion architecture of claim 15, wherein onlypredetermined ones of the TCAM entries are replicated between the SVEs.19. The service insertion architecture of claim 15, wherein loadbalancing weights are applied to the TCAM entries in one of the SVEs.20. A method for providing redundancy in a service insertionarchitecture, comprising: providing a cloud centric network controlpoint (CCN-CP); providing a first services virtualization endpoint (SVE)and a second services virtualization endpoint (SVE) at a virtual IPaddress such that the CCN-CP only sees the first SVE; providing aservice classifier (SCL) that performs traffic classification andservice header insertion; replicating service chaining information fromthe first SVE to the second SVE; redirecting packets received at theSato the first SVE at the virtual IP address; detecting a failure of thefirst SVE; redirecting packets received at the SCL the second SVE at thevirtual IP address; and directing the packets in accordance with amapping for processing.